Integrierte Entwicklung zuverlässiger Software

Modellierungstools und automatische Codegenerierung aus Modellen erlauben es Entwicklern Software top-down zu designen. Modellierung sollte jedoch nicht zur Programmierung jedes Details missbraucht werden. Der algorithmische Anteil eines Projekts kann mit händisch programmiertem Code oft verständlicher, kompakter und effizienter implementiert werden. Um dabei Fehler zu vermeiden, werden statische Analysen eingesetzt. Statische Analysetools werden jedoch vergleichsweise langsam weiterentwickelt, weshalb nur langfristig aus wiederkehrenden Fehlern gelernt wird. Moderne Compiler ermöglichen mit wenig Aufwand neue statische Analysen in den Compiliervorgang zu integrieren. Zudem entstehen Datenbanken von Analysen in der Community, die ohne Aufwand eingebunden werden können. Die existierenden Analysen aus der Community reichen von einfachen Analysen wie der Einhaltung von Namensgebungrichtlinien bis zu aufwändigen Analysen, die verlustbehaftete Gleitkommaberechnungen erkennen oder UMLModelle bei jedem Compiliervorgang gegen den Code prüfen. In diesem Paper wird ein Softwareentwicklungszyklus vorgestellt, der diese transparente und flexible Verwaltung von statischen Analysen in vollem Umfang nutzt. 1 Modellierung vs. Programmierung Model-Driven-Development wird erfolgreich in großen Softwareprojekten eingesetzt. Wegen der Komplexität von Modellierungssprachen wie UML, wird nur eine projektspezifische Untermenge eingesetzt [1] und dann über eine Modell-zu-Code Transformationsspezifikation in Programmcode übersetzt. Bei der Entwicklung der Prozesssteuerungssoftware INSPECT [2] wurden sowohl statische als auch dynamische Aspekte modelliert. Trotz des umfassenden Einsatzes von Modellierung war handgeschriebener Code nicht zu vermeiden. Dieser wurde zwar mit Ada-Restriktionen weiter eingeschränkt, jedoch konnten keine projekteigenen Restriktionen automatisiert geprüft werden. 2 Existierende Schnittstellen 2.1 Open Source Statische-Analyse-Tools Statische-Analyse-Tools wurden mit Lint [3] populär. Wenn Compiler nicht strikt genug sind, werden, besonders bei Open-Source-Projekten, Tools zur statischen Analyse entworfen, bei der jeder Entwickler mit wenig Aufwand neue Analysen selbst entwickeln kann. Am meisten profitierten hiervon bisher dynamische Sprachen wie Ruby [4], Javascript [5] und Haskell [6], da deren Compiler meist viele Konstrukte erlauben, die entweder von der großen Mehrheit der Programmierer als ”unschön” eingestuft werden oder nicht das bedeuten, was intuitiv als die Bedeutung angenommen wird. 2.2 Compilerunterstützung Ein wichtiger Faktor bei der Nutzung von statischen Analysen ist der nötige Aufwand der betrieben werden muss, um die Analysen erstmalig durchzuführen. Damit die statischen Analysen auch regelmäßig durchgeführt werden, muss es möglich sein, diese automatisiert auszuführen. Pluginschnittstellen von Compilern (Rust [7], C/C++ (gcc) [8], C/C++ (clang) [9], scala [10], haskell [11]) bieten die Möglichkeit direkt die Fehlerberichterstattung des Compilers zu nutzen, sowie auf compilerinternes Wissen wie z.B. Typinformationen oder Kontrollflüsse zuzugreifen. Gegenüber klassischen externen Analysetools hat dies den Vorteil, dass keine Codeduplikation (Parser, Typsystem, etc.) stattfindet. Wenn der Compiler jedoch keine Stabilitätsgarantien für die Pluginschnittstelle gibt, kann es vorkommen, dass bei Updates des Compilers auch die Plugins angepasst werden müssen. Keiner der vorgestellten Compiler gibt hierzu Garantien, wobei der Rust Compiler zumindest einen Ausblick für Aufwärtskompatibilität bei Syntaxplugins hat. 3 Beheben von Fehlerklassen statt von Fehlern Oft gibt es fehlerhafte Codekonstrukte, die regelmäßig auftreten. Es ist daher wünschenswert, diese Codekonstrukte generell zu verbieten, statt im Einzelfall zu beheben. Wenn in dem Projekt bereits ein OpenSource Tool für statische Analysen verwendet wird, kann dieses Tool um neue Analysealgorithmen erweitert werden. Dabei gibt es jedoch mehrere Problematiken. Die Entwickler des Tools haben nicht unbedingt die Ansicht, dass das Codekonstrukt generell als fehlerbehaftet zu bezeichnen ist. Außerdem ist es viel Aufwand, sich in eine neue Codebasis einzuarbeiten, vor allem wenn das Tool in einer anderen Sprache oder nach völlig anderen Codingstandards geschrieben ist. 3.1 Statische Analyse als Compilerplugin Es bietet sich an, die Pluginschnittstelle des Compilers zu nutzen, um mit minimalem Aufwand den Code als Datenstruktur analysieren zu können. Ein weiterer Vorteil dieses Ansatzes ist, dass die Fehlermeldungen über den Compiler ausgegeben werden, die dann durch Entwicklungsumgebungen und Continuous Integration bereits verarbeitet werden können und in einem dem Entwickler bereits bekannten Format sind.